Field of the Invention
Example embodiments relate generally to a system and method for congestion detection that is capable of more quickly identifying congestion within a wireless radio access network (RAN) in order to mitigate network congestion.
Related Art
FIG. 1 illustrates a conventional 3rd Generation Partnership Project Long-Term Evolution (3GPP LIE) network 10. The network 10 includes an Internet Protocol (IP) Connectivity Access Network (IP-CAN) 100 and an IP Packet Data Network (IP-PDN) 1001. The IP-CAN 100 generally includes: a serving gateway (SGW) 101; a packet data network (PDN) gateway (PGW) 103; a policy and charging rules function (PCRF) 106; a mobility management entity (MME) 108 and E-UTRAN Node B (eNB) 105 (i.e., base station, for the purposes herein the terms base station and eNB are used interchangeably). Although not shown, the IP-PDN 1001 portion of the EPS may include application or proxy servers, media servers, email servers, etc.
Within the IP-CAN 100, the eNB 105 is part of what is referred to as an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (EUTRAN), and the portion of the IP-CAN 100 including the SGW 101, the PGW 103, the PCRF 106, and the MME 108 is referred to as an Evolved Packet Core (EPC). Although only a single eNB 105 is shown in FIG. 1, it should be understood that the EUTRAN may include any number of eNBs. Similarly, although only a single SGW, PGW and MME are shown in FIG. 1, it should be understood that the EPC may include any number of these core network elements.
The eNB 105 provides wireless resources and radio coverage for one or more user equipments (UEs) 110. That is to say, any number of UEs 110 may be connected (or attached) to the eNB 105. The eNB 105 is operatively coupled to the SGW 101 and the MME 108.
The SGW 101 routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNB handovers of UEs. The SGW 101 also acts as the anchor for mobility between 3rd Generation Partnership Project Long-Term Evolution (3GPP LTE) and other 3GPP technologies. For idle UEs 110, the SGW 101 terminates the downlink data path and triggers paging when downlink data arrives for UEs 110.
The PGW 103 provides connectivity between UE 110 and the external packet data networks (e.g., the IP-PDN) by being the point of entry/exit of traffic for the UE 110. As is known, a given UE 110 may have simultaneous connectivity with more than one PGW 103 for accessing multiple PDNs.
The PGW 103 also performs policy enforcement, packet filtering for UEs 110, charging support, lawful interception and packet screening, each of which are well-known functions. The PGW 103 also acts as the anchor for mobility upon SGW relocation during handovers within LTE network, as well as between 3GPP and non-3GPP technologies, such as Worldwide Interoperability for Microwave Access (WiMAX) and 3rd Generation Partnership Project 2 (3GPP2 (code division multiple access (CDMA) 1× and Enhanced Voice Data Optimized (EvDO)).
Still referring to FIG. 1, eNB 105 is also operatively coupled to the MME 108. The MME 108 is the control-node for the EUTRAN, and is responsible for idle mode UE 110 paging and tagging procedures including retransmissions. The MME 108 is also responsible for choosing a particular SGW for a UE during initial attachment of the UE to the network, and during intra-LTE handover involving Core Network (CN) node relocation. The MME 108 authenticates UEs 110 by interacting with a Home Subscriber Server (HSS), which is not shown in FIG. 1.
Non Access Stratum (NAS) signaling terminates at the MME 108, and is responsible for generation and allocation of temporary identities for UEs 110. The MME 108 also checks the authorization of a UE 110 to camp on a service provider's Public Land Mobile Network (PLMN), and enforces UE 110 roaming restrictions. The MME 108 is the termination point in the network for ciphering/integrity protection for NAS signaling, and handles security key management.
The MME 108 also provides control plane functionality for mobility between LTE and 2G/3G access networks with an S3 type of interface from the SGSN (not shown) terminating at the MME 108.
The Policy and Charging Rules Function (PCRF) 106 is the entity that makes policy decisions and sets charging rules. It has access to subscriber databases and plays a role in the 3GPP architecture as specified in 3GPP TS 23.203 “Policy and Charging Control Architecture.”
FIG. 2 illustrates a conventional E-UTRAN Node B (eNB) 105. The eNB 105 includes: a memory 225; a processor 210; a scheduler 215; wireless communication interfaces 220; radio link control (RLC) buffers 230 for each bearer; and a backhaul interface 235. The processor or processing circuit 210 controls the function of eNB 105 (as described herein), and is operatively coupled to the memory 225 and the communication interfaces 220. While only one processor 210 is shown in FIG. 2, it should be understood that multiple processors may be included in a typical eNB 105. The functions performed by the processor may be implemented using hardware. Such hardware may include one or more Central Processing Units (CPUs), digital signal processors (DSPs), application-specific-integrated-circuits, field programmable gate arrays (FPGAs) computers or the like. The term processor, used throughout this document, may refer to any of these example implementations, though the term is not limited to these examples. With a Virtual Radio Access Network (VRAN) architecture various functions eNB components may be distributed across multiple processing circuits and multiple physical nodes within VRAN cloud.
The eNB 105 may include one or more cells or sectors serving UEs 110 within individual geometric coverage sector areas. Each cell individually may contain elements depicted in FIG. 2. Throughout this document the terms eNB, cell or sector shall be used interchangeably.
Still referring to FIG. 2, the communication interfaces 220 include various interfaces including one or more transmitters/receivers connected to one or more antennas to wirelessly transmit/receive control and data signals to/from UEs 110, or via a control plane. Backhaul interface 235 is the portion of eNB 105 that interfaces with SGW 101, MME 108, other eNBs, or interface to other EPC network elements and/or RAN elements within IP-CAN 100. The scheduler 215 schedules control and data communications that are to be transmitted and received by the eNB 105 to and from UEs 110. The memory 225 may buffer and store data that is being processed at eNB 105, transmitted and received to and from eNB 105.
Every Transmission Time Interval (TTI), typically equal to 1 millisecond, the scheduler 215 may allocate a certain number of Physical Resource Blocks (PRBs) to different bearers carrying data over the wireless link in the Downlink direction (i.e., transmitting buffered data, located in buffer 230, from eNB 105 to UE 110) and Uplink direction (i.e., receiving data at eNB 105 from UE 110, which is received over backhaul 235, and placed in buffer 230). A “bearer” may be understood to be a virtual link, channel, or data flow used to exchange information for one or more applications on the UE 110. The scheduler 215 may determine Modulation and Coding Schema (MCS) that may define how many bits of information may be packed into the allocated number of PRBs. The latter is defined by the 3GPP TS36.213 tables 7.1.7.1-1 and 7.1.7.2.1-1 (the contents of which is incorporated by reference in its entirety), which presents a lookup table for a number of bits of data that may be included in PRBs sent per TTI for a given allocated number of PRBs and a MCS value. MCS is computed by the scheduler using Channel Quality Indicator (CQI) values reported by the UE 110 that in turn may be derived from measured UE 110 wireless channel conditions in the form of Signal to Interference and Noise Ratio (SINR).
Scheduler 215 may make PRB allocation decisions based upon a Quality of Service (QoS) Class Identifier (QCI), which represents traffic priority hierarchy. There are nine QCI classes currently defined in LTE, with 1 representing highest priority and 9 representing the lowest priority. QCIs 1 to 4 are reserved for Guaranteed Bitrate (GBR) classes for which the scheduler maintains certain specific data flow QoS characteristics. QCIs 5 to 9 are reserved for various categories of Best Effort traffic.
While the scheduler 215 operations are not standardized, there are certain generic types of schedulers that are generally accepted. Examples include strict priority scheduler (SPS) and proportional weighted fair share scheduler (PWFSS). Both types try to honor GBR needs first by allocating dedicated resources to meet whenever possible the GBR bearer throughput constraints while leaving enough resources to maintain certain minimal data traffic for non-GBR classes. The SPS allocates higher priority classes with the resources that may be needed (except for a certain minimal amount of resources to avoid starving lower priority classes), and lower priority classes generally receive the remaining resources. The PWFSS gives each non-GBR QCI class certain weighted share of resources that may not be exceeded unless unutilized resources are available.
Cell congestion in the wireless RANs of LTE (and other technologies) present significant challenges in quality of experience (QoE) degradation for mobile users. While an increase in mobile video traffic is one of the main contributors to cell congestions, QoS degradation due to the congestion may also be drastic for mobile video users. Fast congestion detection is therefore an important but difficult challenge. While standard 3GPP TR23.705 discusses a variety of standardization options for reporting and managing congestion in the wireless RAN and core to combat QoE issues, 3GPP TR23.705 and other related standards do not describe an actual process for detecting congestion.
Fast (within seconds) congestion detection is particularly important in providing opportunities for significant improvement in congestion mitigation and reduction in the end user QoE impact. However, providing such fast detection can be challenging. Existing congestion detection mechanisms utilizing monitoring that is external to eNB traffic may not detect congestion quickly enough, as this type of detection may require a time period of 1 minute or longer before congestion is detected. This length of delay in detection time will generally adversely impact the end user QoE, especially in the case of mobile video applications.
Existing mechanisms of cell congestion detection using the measures such as UE throughput, a number of UEs being served, or percentage of cell load, may not be adequate, for the following reasons. Detecting cell congestion based upon UE throughput is inadequate, since UE throughput in wireless networks is usually also a function of channel conditions, whereas cell congestion detection should not depend upon channel conditions of individual UEs. Detecting cell congestion based upon an increased number of active UEs being served is inadequate, as many UEs may be passing very light traffic and therefore this measure may not have a significant impact on an amount of throughput that an additional UE joining the cell may receive. Detecting cell congestion based upon an increased percentage of cell load is inadequate, as one or two users in an LTE network may fully load the cell due to amount of traffic that these users are monopolizing through heavy downloading, thereby skewing a true measure of cell congestion. Conventional network congestion end-to-end detection mechanisms based upon end-to-end packet loss or packet delay may cause too many false positives if used to detect cell congestion, due to variability of wireless channel conditions that also skew cell congestion detection.